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Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   The Internet Key Exchange (IKEv2) protocol supports several
   mechanisms for authenticating the parties, including signatures with
   public-key certificates, shared secrets, and Extensible
   Authentication Protocol (EAP) methods.  Currently, each endpoint uses
   only one of these mechanisms to authenticate itself.  This document
   specifies an extension to IKEv2 that allows the use of multiple
   authentication exchanges, using either different mechanisms or the
   same mechanism.  This extension allows, for instance, performing
   certificate-based authentication of the client host followed by an
   EAP authentication of the user.  When backend authentication servers
   are used, they can belong to different administrative domains, such
   as the network access provider and the service provider.
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1.  Introduction

   IKEv2 [IKEv2] supports several mechanisms for parties involved in the
   IKE_SA (IKE security association).  These include signatures with
   public-key certificates, shared secrets, and Extensible
   Authentication Protocol (EAP) methods.

   Currently, each endpoint uses only one of these mechanisms to
   authenticate itself.  However, there are scenarios where making the
   authorization decision in IKEv2 (whether to allow access or not)
   requires using several of these methods.

   For instance, it may be necessary to authenticate both the host
   (machine) requesting access, and the user currently using the host.
   These two authentications would use two separate sets of credentials
   (such as certificates and associated private keys) and might even use
   different authentication mechanisms.

   To take another example, when an operator is hosting a Virtual
   Private Network (VPN) gateway service for a third party, it may be
   necessary to authenticate the client to both the operator (for
   billing purposes) and the third party's Authentication,
   Authorization, and Accounting (AAA) server (for authorizing access to
   the third party's internal network).

   This document specifies an extension to IKEv2 that allows the use of
   multiple authentication exchanges, using either different mechanisms
   or the same mechanism.  This extension allows, for instance,
   performing certificate-based authentication of the client host
   followed by an EAP authentication of the user.

   Each authentication exchange requiring communication with backend AAA
   servers may be directed to different backend AAA servers, located
   even in different administrative domains.  However, details of the
   communication between the IKEv2 gateway and the backend
   authentication servers are beyond the scope of this document.  In
   particular, this document does not specify any changes to existing
   AAA protocols, and it does not require the use of any particular AAA
   protocol.

   In case of several EAP authentications, it is important to notice
   that they are not a "sequence" (as described in Section 2.1 of
   [EAP]), but separate independent EAP conversations, which are usually
   also terminated in different EAP servers.  Multiple authentication
   methods within a single EAP conversation are still prohibited as
   described in Section 2.1 of [EAP].  Using multiple independent EAP
   conversations is similar to the separate Network Access Provider
   (NAP) and Internet Service Provider (ISP) authentication exchanges
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   planned for [PANA].  The discovery of the appropriate EAP server for
   each EAP authentication conversation is based on AAA routing.

1.1.  Usage Scenarios

   Figure 1 shows an example architecture of an operator-hosted VPN
   scenario that could benefit from a two-phase authentication within
   the IKEv2 exchange.  First, the client authenticates towards the
   Network Access Provider (NAP) and gets access to the NAP-hosted VPN
   gateway.  The first-phase authentication involves the backend AAA
   server of the NAP.  After the first authentication, the client
   initiates the second authentication round that also involves the
   Third Party's backend AAA server.  If both authentications succeed,
   the required IPsec tunnels are set up and the client can access
   protected networks behind the Third Party.


       Client                         *Network Access Provider*
     +---------+                    +---------+              +-----+
     |         |                    |  NAP's  |              | NAP |
     |Protected|     IPsec SAs      | Tunnel  | AAA Protocol | AAA |
     |Endpoint |<------------------>|Endpoint |<------------>|Serv/|
     |         |                    |         |              |Proxy|
     +---------+                    +---------+              +-----+
                                       ^                        ^
                            IPsec or  /                  AAA    |
                        Leased Line  /                 Protocol |
                                    /                           |
                                   v                            |
                           +---------+    *Third Party*         v
                           |3rd Party|                       +-----+
            Protected      | Tunnel  |                       | 3rd |
               Subnet <----|Endpoint |                       |Party|
                           |         |                       | AAA |
                           +---------+                       +-----+

          Figure 1: Two-phase authentication used to gain access to
          the Third Party network via Network Access Provider.  AAA
          traffic goes through NAP's AAA server.

   The NAP's AAA server can be used to proxy the AAA traffic to the
   Third Party's backend AAA server.  Alternatively, the AAA traffic
   from the NAP's tunnel endpoint could go directly to the Third Party's
   backend AAA servers.  However, this is more or less an AAA routing
   issue.
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1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

   The terms and abbreviations "authenticator", "backend authentication
   server", "EAP server", and "peer" in this document are to be
   interpreted as described in [EAP].

   When messages containing IKEv2 payloads are described, optional
   payloads are shown in brackets (for instance, "[FOO]"), and a plus
   sign indicates that a payload can be repeated one or more times (for
   instance, "FOO+").

2.  Solution

2.1.  Solution Overview

   The peers announce support for this IKEv2 extension by including a
   MULTIPLE_AUTH_SUPPORTED notification in the IKE_SA_INIT response
   (responder) and the first IKE_AUTH request (initiator).

   If both peers support this extension, either of them can announce
   that it wishes to have a second authentication by including an
   ANOTHER_AUTH_FOLLOWS notification in any IKE_AUTH message that
   contains an AUTH payload.  This indicates that the peer sending the
   ANOTHER_AUTH_FOLLOWS wishes to authenticate another set of
   credentials to the other peer.  The next IKE_AUTH message sent by
   this peer will contain a second identity payload (IDi or IDr) and
   starts another authentication exchange.  The IKE_AUTH phase is
   considered successful only if all the individual authentication
   exchanges complete successfully.

   It is assumed that both peers know what credentials they want to
   present; there is no negotiation about, for instance, what type of
   authentication is to be done.  As in IKEv2, EAP-based authentication
   is always requested by the initiator (by omitting the AUTH payload).

   The AUTH payloads are calculated as specified in [IKEv2] Sections
   2.15 and 2.16, where IDi' refers to the latest IDi payload sent by
   the initiator, and IDr' refers to the latest IDr payload sent by the
   responder.  If EAP methods that do not generate shared keys are used,
   it is possible that several AUTH payloads with identical contents are
   sent.  When such EAP methods are used, the purpose of the AUTH
   payload is simply to delimit the authentication exchanges, and ensure
   that the IKE_SA_INIT request/response messages were not modified.
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2.2.  Example 1: Multiple EAP Authentications

   This example shows certificate-based authentication of the responder
   followed by an EAP authentication exchange (messages 1-10).  When the
   first EAP exchange is ending (the initiator is sending its AUTH
   payload), the initiator announces that it wishes to have a second
   authentication exchange by including an ANOTHER_AUTH_FOLLOWS
   notification (message 9).

   After this, a second authentication exchange begins.  The initiator
   sends a new IDi payload but no AUTH payload (message 11), indicating
   that EAP will be used.  After that, another EAP authentication
   exchange follows (messages 12-18).

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                             <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                          N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERTREQ+], [IDr],
                   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) }  -->
                             <--  4. HDR, SK { IDr, [CERT+], AUTH,
                                               EAP(Request) }
      5. HDR, SK { EAP(Response) }  -->
                             <--  6. HDR, SK { EAP(Request) }
      7. HDR, SK { EAP(Response) }  -->
                             <--  8. HDR, SK { EAP(Success) }
      9. HDR, SK { AUTH,
                   N(ANOTHER_AUTH_FOLLOWS) }  -->
                             <--  10. HDR, SK { AUTH }
      11. HDR, SK { IDi }  -->
                             <--  12. HDR, SK { EAP(Request) }
      13. HDR, SK { EAP(Response) }  -->
                             <--  14. HDR, SK { EAP(Request) }
      15. HDR, SK { EAP(Response) }  -->
                             <--  16. HDR, SK { EAP(Success) }
      17. HDR, SK { AUTH }  -->
                             <--  18. HDR, SK { AUTH, SA, TSi, TSr }

          Example 1: Certificate-based authentication of the
          responder, followed by two EAP authentication exchanges.
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2.3.  Example 2: Mixed EAP and Certificate Authentications

   Another example is shown below: here both the initiator and the
   responder are first authenticated using certificates (or shared
   secrets); this is followed by an EAP authentication exchange.

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                             <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                          N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
                   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
                   N(ANOTHER_AUTH_FOLLOWS) }  -->
                             <--  4. HDR, SK { IDr, [CERT+], AUTH }
      5. HDR, SK { IDi }  -->
                             <--  6. HDR, SK { EAP(Request) }
      7. HDR, SK { EAP(Response) }  -->
                             <--  8. HDR, SK { EAP(Request) }
      9. HDR, SK { EAP(Response) }  -->
                             <--  10. HDR, SK { EAP(Success) }
      11. HDR, SK { AUTH }  -->
                             <--  12. HDR, SK { AUTH, SA, TSi, TSr }

             Example 2: Certificate-based (or shared-secret-based)
             authentication of the initiator and the responder,
             followed by an EAP authentication exchange.
























Eronen & Korhonen             Experimental                      [Page 7]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006


2.4.  Example 3: Multiple Initiator Certificates

   This example shows yet another possibility: the initiator has two
   different certificates (and associated private keys), and
   authenticates both of them to the responder.

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                             <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                          N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
                   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
                   N(ANOTHER_AUTH_FOLLOWS) }  -->
                             <--  4. HDR, SK { IDr, [CERT+], AUTH }
      5. HDR, SK { IDi, [CERT+], AUTH }  -->
                             <--  6. HDR, SK { SA, TSi, TSr }

          Example 3: Two certificate-based authentications of the
          initiator, and one certificate-based authentication
          of the responder.

2.5.  Example 4: Multiple Responder Certificates

   This example shows yet another possibility: the responder has two
   different certificates (and associated private keys), and
   authenticates both of them to the initiator.

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                             <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                          N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
                   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) }  -->
                             <--  4. HDR, SK { IDr, [CERT+], AUTH,
                                               N(ANOTHER_AUTH_FOLLOWS) }
      5. HDR, SK { }  -->
                             <--  6. HDR, SK { IDr, [CERT+], AUTH,
                                               SA, TSi, TSr }

          Example 4: Two certificate-based authentications of the
          responder, and one certificate-based authentication
          of the initiator.
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3.  Payload Formats

3.1.  MULTIPLE_AUTH_SUPPORTED Notify Payload

   The MULTIPLE_AUTH_SUPPORTED notification is included in the
   IKE_SA_INIT response or the first IKE_AUTH request to indicate that
   the peer supports this specification.  The Notify Message Type is
   MULTIPLE_AUTH_SUPPORTED (16404).  The Protocol ID and SPI Size fields
   MUST be set to zero, and there is no data associated with this Notify
   type.

3.2.  ANOTHER_AUTH_FOLLOWS Notify Payload

   The ANOTHER_AUTH_FOLLOWS notification payload is included in an
   IKE_AUTH message containing an AUTH payload to indicate that the peer
   wants to continue with another authentication exchange.  The Notify
   Message Type is ANOTHER_AUTH_FOLLOWS (16405).  The Protocol ID and
   SPI Size fields MUST be set to zero, and there is no data associated
   with this Notify type.

4.  IANA Considerations

   This document defines two new IKEv2 notifications,
   MULTIPLE_AUTH_SUPPORTED and ANOTHER_AUTH_FOLLOWS, whose values are
   allocated from the "IKEv2 Notify Message Types" namespace defined in
   [IKEv2].

   This document does not define any new namespaces to be managed by
   IANA.

5.  Security Considerations

   Security considerations for IKEv2 are discussed in [IKEv2].  The
   reader is encouraged to pay special attention to considerations
   relating to the use of EAP methods that do not generate shared keys.
   However, the use of multiple authentication exchanges results in at
   least one new security consideration.

   In normal IKEv2, the responder authenticates the initiator before
   revealing its identity (except when EAP is used).  When multiple
   authentication exchanges are used to authenticate the initiator, the
   responder has to reveal its identity before all of the initiator
   authentication exchanges have been completed.
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